fix(agent): follow a parallel Stream's map, filter, reduce and collect lambdas (#1172) - #1209

Partly addresses #1172 (reference Stream pipelines; primitive streams' intermediate operations stay open).

Why

Only a parallel forEach's action carried the run to the common pool's workers (#1156). A plain counter or a shared ArrayList inside a parallel map lambda was seen only on the caller's own elements, so the commonest parallel-stream mistakes after forEach drew nothing reliable.

A lambda given to Stream.map, filter or peek now waits in a slot. The woven terminal operation (forEach, forEachOrdered, collect, reduce, min, max, the matches, toList, toArray, count, the finds) lends the run to every slot of its pipeline while it runs, and runs its own lambdas like forEach's action. A pipeline ended by an unwoven terminal such as iterator() lends nothing. With no join there to order the caller after the helpers, lending would report reading a result as a race.

A combiner, a reduce operator or a comparator merges what other subtasks built, after a fork and join the agent does not see. Each element now publishes its thread's clock, the caller's included, and those three receive every clock published so far before they run.

How it was verified

• Tests first in AgentParallelStreamHooksTest: pipeline and terminal lambdas run for the run on helpers, the caller is ordered after a map lambda once collect returns, an iterator() pipeline lends nothing, and every woven form returns the stream's own answer.
• Two combiner tests failed before the combine rule, reporting a correct three-argument collect and a reduce over objects built on other workers as races. Both now pass, and the class passed three consecutive runs.
• Corpus, through the real agent, four new idioms: parallelMap_plainCounter and parallelMap_addsToAnArrayList fire PROMPT/HIGH; parallelMap_countsUnderALock and parallelCollect_containerPerSubtask stay silent. 0 false positives, every gate green.
• Full library suite: 3921 tests, 0 failures. Agent suite green, including SubstitutionHooksArePointsTest.

Checklist

• A behaviour change ships with a test that fails without the fix
• A new or changed detector is tested against the buggy code and its correctly synchronized twin, and its reported severity matches what it can actually prove
• Docs the change makes wrong are updated in this same change
• Nothing was hand-edited between VIBETAGS-START / VIBETAGS-END markers
• Public API changes are intentional and carry the right version bump: 21 new public static hooks on AgentConcurrencyUtilHooks, additive, tagged @since 1.14.2. Change the tag if the next release gets another number.
• Commits an agent authored carry the Co-Authored-By trailer
• A new dependency was proposed with a reason (none added)
• CI is green, or the failure is explained below

Anything reviewers should push back on

• The combine rule receives every clock published so far, not only those of the two subtasks being merged. It can therefore order a combine after a subtask it does not merge. That edge is real (it goes through the map carrying the clocks), but it can hide a race between such a combine and an unrelated subtask.
• Pipelines are tracked in a synchronized WeakHashMap keyed by the stream, only inside a run.
• Not followed yet: a primitive stream's map and filter, a stage behind an unwoven one (sorted, distinct, limit, mapToInt), and a Collector's own functions. All of these run unattributed as before and are documented in docs/agent/limitations.md.

Second commit: the clock cap dropped the common pool's threads

Corpus Eval failed on JDK 25 and 26: idiom_parallelCollect_containerPerSubtask, a correct three-argument collect, drew a SharedCollectionDetector finding. By then the corpus JVM had started about 18,000 workers. A happens-before clock keeps 4,096 threads (#840) and dropped the lowest ids first. The common pool's threads have the lowest ids and are still running, so a combine dropped the entry of the pool thread whose container it was merging. The same loss affected the read after a parallel forEach (#1156) in any suite that had started that many threads.

HappensBefore.Stamp.join now drops ended threads first, lowest ids first, then the lowest ids of running ones. Either way it only ever loses an edge.

• Failing first: AgentParallelStreamHooksTest.aCombinerStaysOrderedPastTheClockCap and HappensBeforeTest.theCapDropsEndedThreadsFirst both failed on JDK 26 before the fix. The first one's full clock also turned three existing ordering tests red in the same JVM.
• After the fix: library suite 3923 green on JDK 26, static gates green on JDK 21, corpus eval green on JDK 26 in every lane (idiom lane 82/82).
• Docs: CHANGELOG entry, HappensBefore class and join javadoc. No VibeTags guardrail added: the drop rule is documented where it lives, and no external contract changed.

Third commit: obtrude analysis vs. a record still being written

Test Suite (21) failed in DetectorAnalysisUnderConcurrentWritesTest: CompletableFutureObtrudeDetector.analyze() threw a NullPointerException while another thread was still recording, because the thread name was not set yet and the null went into Map.of. This bug was already there before this PR (the test came with #1150). analyze() now skips a record that is not complete yet. The new test failed without the fix and passes with it, on JDK 21.

🤖 Generated with Claude Code